Feat/control service object status #2912
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2912 +/- ##
==========================================
- Coverage 23.75% 23.53% -0.23%
==========================================
Files 774 776 +2
Lines 44866 45302 +436
==========================================
Hits 10660 10660
- Misses 33356 33792 +436
Partials 850 850 ☔ View full report in Codecov by Sentry. |
| // resynchronized state when meta knows nothing about | ||
| // stored objects in blob; however, it is a control | ||
| // service, not a debug util | ||
| continue |
There was a problem hiding this comment.
IIUC ur comment: if it is in write cache and/or blob storage, some info should be returned anyway. We can fallback this case to MISSING status for metabase
There was a problem hiding this comment.
if it is in write cache and/or blob storage, some info should be returned anyway
that is why i left comment: i do not think we should search for a object if a metabase in this shard does not know it. this is not neofs-lens, it is a control service
There was a problem hiding this comment.
// can be reconsidered
what do u mean then?
There was a problem hiding this comment.
i meant somebody can disagree and we may change it in the future. if too many devs disagree now, may change it now
There was a problem hiding this comment.
let bs/wc aint in sync with mb - what output will be currently shown? And what GET would respond
There was a problem hiding this comment.
let bs/wc aint in sync with mb - what output will be currently shown?
if bs/wc has info, but metabase does not know about an object, it will be <empty response> currently
And what GET would respond
it really depends on the degree of resynchronization, it meta know absolutely nothing about an object, then it is 404:
neofs-node/pkg/local_object_storage/shard/get.go
Lines 146 to 148 in 73e8414
carpawell
force-pushed
the
feat/control-service-object-status
branch
2 times, most recently
from
9d9de7e
to
c64da4d
Compare
carpawell
force-pushed
the
feat/control-service-object-status
branch
from
c64da4d
to
dd9291f
Compare
Includes API definition extending; server side implementation; protoc version update (my local version is higher, and it seems we do not have a strict policy about the version). The command requests server's storage engine (bypass any other logical check, only storage) to answer its status according to its parts (shards and their write-caches, blobstors, metabases), Signed-off-by: Pavel Karpy <[email protected]>
carpawell
force-pushed
the
feat/control-service-object-status
branch
from
dd9291f
to
d1d6303
Compare
It is the second command related to object operations, so additional `object`
subcommand seems reasonable, in the future, the others can be placed (move to)
here too.
Example:
```
▶ neofs-cli control object status --endpoint s01.neofs.devenv:8081 -w services/storage/wallet01.json --object EnCqHUUwS6vd2MENDe1MvjiXv9jADF8iA1vZimpjJpYt/AWUFtrRLU8NkPVyF3b5WjMXUe8awxPdHtNvSRpKqEaFq
Enter password >
Shard ID: 66cJzDxA4hqqF3YKFiqFyc
metabase: AVAILABLE
peapod: Path: "/storage/peapod1.db"
```
Closes #2886.
Signed-off-by: Pavel Karpy <[email protected]>
carpawell
force-pushed
the
feat/control-service-object-status
branch
from
d1d6303
to
c4fda9d
Compare
No description provided.